The invention relates to a process for providing services in a telecommunication network in accordance with IN architecture (IN=intelligent network), as described for example in the article “Intelligent Network Products ”, published in “Electrical Communication”, Vol., 63, No. 4, 1989, p. 321 to 330, by J. P. Euzen and J. B. Kérihuel.
A telecommunications network comprises a plurality of service switching units (SSP), usually part of a service exchange, which are connected via signalling system number 7 to a plurality of service control units (SCP) forming a service control plane of the telecommunication network. Services are provided for subscribers of the telecommunication network. The service switching unit detects specific trigger events, for example a special prefix dialed by a subscriber, which indicates that a calling subscriber requires access to an IN service. If, upon the establishment of a connection in which it is a participant, a service switching unit detects such a trigger event, it transmits a service request message to the service control unit which has a service logic function for the required IN service. The service logic function represents a control program which, as soon as it is activated by the service request message, controls the execution of the required IN service. For the provision of the required IN service, the activated service logic function of the service control unit then interacts with the service switching unit. When the required IN service has been provided, the dialog between service switching unit and service control unit and the execution of the service logic program are terminated.
A known improvement of the above described classical IN architecture is based on the principle of splitting the service control plane, which controls the provision of services in a telecommunications network of an operator, into a two-layer structure. For each service request message, an infrastructure manager (LL-SCP), introduced as lower layer of the service control plane, is responsible for pure network functionality. Then, the infrastructure manager distributes the service request message to one of the service control units, introduced as upper layer of the service control plane, and responsible for pure service functionality.
This improvement facilitates an open service. Complex service scenarios are thus rendered possible. Service number portability functions are typically provided by the infrastructure manager. The service management is thereby simplified and the service specific units are relieved of these infrastructure tasks, which can thus be executed more rapidly.
In a 2-layer IN architecture, the provision of services is, as known from prior art, based on application relay. FIG. 1 represents a flow diagram illustrating the provision of a IN service based on application relay. A subscriber terminal T, for example a PSTN or a ISDN terminal, of a IN-capable telecommunication exchange wants to access a service offered by the telecommunication network. When the service number dialed by the subscriber is received at an IN-capable exchange of the telecommunication network, a service switching unit SSP is triggered and generates a service request message comprising a service identification univocally determining the service corresponding to the dialed service number. The service identification is preferably the service number itself of the required service. The service request message is transmitted over a signaling transfer point STP to a service control plane of the telecommunication network comprising an infrastructure manager LL-SCP and a service specific unit HL-SCP. The service request message is first transmitted to the infrastructure manager LL-SCP. A first dialog following the paths 11, 12, 13, 14 is established between the service switching unit SSP and the infrastructure manager LL-SCP. The infrastructure manager executes network specific functions, for example determine the address of the service specific unit HL-SCP by which the service requested in the service request message has to be provided. The infrastructure manager LL-SCP then establishes, in parallel to the first dialog, a second dialog following the paths 15, 16, 17, 18 over the signalling transfer point STP to the appropriate service specific unit HL-SCP which in turn execute a service logic function for the required IN service. The two dialogs remain active during the whole duration of the service provision and all messages between the service switching unit SSP and the service specific unit HL-SCP have to follow successively the paths 11, 12, 15, 16, 17, 18, 13, 14 over the infrastructure manager LL-SCP.
It is also particularly advantageous to provide INAP converter functions (INAP=intelligent network application protocol) in the infrastructure manager LL-SCP. In this way, cooperation between products of different producers and the use of existing devices is facilitated.